IBIS Macromodel Task Group Meeting date: 01 December 2015 Members (asterisk for those attending): ANSYS: * Dan Dvorscak * Curtis Clark Avago (LSI): Xingdong Dai Bob Miller Cadence Design Systems: Ambrish Varma Brad Brim Kumar Keshavan Ken Willis Cisco: Seungyong (Brian) Baek eASIC: David Banas Marc Kowalski Ericsson: Anders Ekholm GlobalFoundries: Steve Parker Intel: Michael Mirmak Keysight Technologies: * Fangyi Rao Radek Biernacki Maxim Integrated Products: Hassan Rafat Mentor Graphics: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield QLogic Corp.: James Zhou Andy Joy SiSoft: * Walter Katz Todd Westerhoff * Mike LaBonte Synopsys: Rita Horner Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong The meeting was led by Arpad Muranyi. ------------------------------------------------------------------------ Opens: - Arpad reviewed upcoming ATM meeting dates and proposed that we cancel the meetings on December 22nd and 29th. Therefore, we will meet December 8th, December 15th, and then not until January 5, 2016. No one objected to this plan. Walter noted that he will not be able to attend on December 15th. -------------------------- Call for patent disclosure: - None. ------------- Review of ARs: - None. ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections? [none] - Walter: Motion to approve the minutes. - Arpad: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: New Redriver Flow BIRD: - Arpad: I would like to start with an update on the state of the offline discussions on this topic. - Walter: Fangyi and I agree on two issues: - 1. The existing flow is incorrect when Rx models have optimization loops in them, for example for a DFE. - 2. The BIRD I sent to Fangyi states that for a statistical flow we have to change the order of what gets input to the Rx. - Arpad: You mentioned "optimization," could you clarify if this only applies if the models have optimizations in the algorithms, or if the DFE block is there at all? - Walter: It applies if there is optimization inside the model. - If the equalization applied in the Rx is a function of its input, then its input must include the info from the IR that went into the redriver Tx. - It's independent of the type of equalization, linear or not, etc. If the Rx model is optimizing itself based on its input IR then the existing flow has this problem. - Walter: We had an interesting discussion: - What do you do if you're doing a time domain flow (Tx has GetWave()) and the downstream Rx does not have an AMI GetWave()? - There may be things you can do to make it better. - We couldn't agree on anything that rigorously solves the issue. - We just have difficulty when an Rx doesn't have a GetWave() and you're forced to use GetWave() upstream and the Rx optimizes itself based on its input IR. - As a practical matter nearly all Rx models optimize themselves. - We could not agree to a change in flow or alternative inputs, etc. All the solutions were problematic. A DFE is non-linear and one gets into problems if it is not simply used as part of the main channel simple statistical flow. - I think Fangyi and I agree that if a model maker can write an Rx AMI_Init() function that does what they want, then there is no reason they can't just write a GetWave() function to apply that equalization to whatever is passed in to GetWave(). - We think it's ill-advised for a model maker to create optimizing Rx models that are Init() only. - Fangyi thinks we should require that such models have a GetWave(). - Perhaps "strongly suggest" that GetWave() be provided. - Maybe it's a quality or best-practices issue. - It would be a lot easier for us to have model makers put GetWave() into their Rx models, rather than having us try to define alternative IR inputs into the AMI_Init() function. - Discussion: Fangyi agreed with Walter's summary. Arpad commented that if we didn't require model makers to provide GetWave() functions with their Rx models, then we would still have to deal with the possibility of Init() only models. Fangyi agreed and said that this was why he still felt that we needed to add the additional IR to be passed into the Init() function, so we could deal with the Tx GetWave(), Rx Init() only scenario. Walter commented that using deconvolution to the get the equalization of the Rx and then applying that to the Tx GetWave() output convolved with the downstream channel was another alternative. Walter suggested that Fangyi could draft the proposal specifying the additional IR to be passed in, defining a new Reserved Parameter to indicate that it was there, etc. Fangyi said that he probably wouldn't get to this until the new year. Mike L. asked if adding the additional IR would mean that we needed to revisit any of the mathematical process descriptions in the spec. Fangyi said we would not, and Walter agreed. Discussion of language corrections regarding "ground": - Arpad: We need to start by deciding on a few things: - I think it might be easier to make these changes by editing the main 6.1 document. If we run into additional major or technical changes, then we could write additional BIRDs for those changes. - Should we start additional meetings in the normal Friday time slot for the editorial meetings, or should we simply work on it here in this meeting? - Discussion: Walter stated that he thought that the only way the process would be manageable would be to edit the 6.1 specification directly. Then we could generate a diff when the changes were completed and use the diff to draft a single BIRD describing the changes. He also thought that we would be unlikely to run into anything that would require drafting separate additional BIRDs. No one disagreed with this approach. Mike did suggest that we might want to keep some additional notes during the discussion, as he was concerned that we had enough documentation of any changes in the event that we pursued adopting IBIS 6.2 as a formal standard. Bob suggested that we might simply keep a list of the pages on which changes were made, as a supplement to the final diff of the changes, to help with drafting the final BIRD. Walter and Arpad asked if anyone objected to this proposed process. No one did. Arpad then suggested that the ATM meetings were not particularly busy at this time, so we could work on these changes in the ATM meetings. Everyone agreed that we would start this way and potentially open up the Friday time slot for this work if the ATM meeting became busy with additional topics. Arpad suggested that we should have an editor-in-chief for this process. Bob said that he would like to see if Michael Mirmak were willing to take on this role, as he had done it well and consistently in the past. Mike and Bob said they would contact Michael Mirmak. Michael Mirmak was also believed to be the keeper of the original Visio figures in the spec., some of which may need to be edited. Discussion of issue discovered with ibischk 6.1.0 - Bob: We have a problem with ibischk 6.1.0 when checking matrix based [Package Models], primarily due to numerical resolution. - New off diagonal testing rules may produce many failures in working [Package Models]. - Be careful implementing this version in tools. Wait for the next version of ibischk. For instance, summation of off diagonal elements might yield a magnitude greater than the diagonal element just due to numerical issues. - Discussion: Walter suggested a tolerancing scheme based on 1e-4 (or some other multiple) times the sum of the absolute values of the elements in the row. Bob said a similar tolerancing scheme was being introduced. Walter asked if the Capacitance matrix diagonal checking was based on passivity, and said that 1e-3 was probably a tight enough tolerance in that case. Mike mentioned that in his testing about 50% of the files that failed with zero tolerance passed when he implemented a tolerance of 1e-5 * (the sum of absolute values). But he had to go to 1e-3 before all examples passed. Randy then said that Mike had in fact found some examples of bad package models. Randy wanted to look into those bad package models before suggesting a tolerance. Mike and Bob said they were implementing a two tiered scheme with separate thresholds for warning and error. Randy agreed to get back to them with suggestions for the two thresholds. - Arpad: Thank you all for joining. ------------- Next meeting: 08 December 2015 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives